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I.  Introduction 

The  purpose  of  this  document  is  to  describe  a  set  of  preliminary  high  level  requirements  that  the 
SecureCore  hardware  base  (SCHW)  must  satisfy.  To  provide  a  coherent  view  of  the  desired 
hardware  features,  the  features  described  herein  include  those  that  are  currently  available  (“C”), 
are  part  of  the  next  generation  (“TV”  e.g.,  Intel’s  VTx),  and  those  proposed  for  the  future  (“F”). 1 
In  regard  to  the  latter,  we  are  currently  engaged  in  NDA-level  discussions  with  Intel.  This 
document  assumes  the  reader  is  familiar  with  the  SecureCore  architecture  provided  in  the 
SecureCore  project  description  [1]. 


II.  SCHW  Architecture  Overview 

A  SecureCore  component  is  intended  to  be  a  mobile  networked  device  capable  of  operating  in 
different  modes  with  different  levels  of  trust.  Security  features  implemented  in  the  SecureCore 
architecture  must  minimize  changes  to  existing  application-level  software  to  promote  rapid  user 
acceptability.  The  current  trend  in  hardware-assisted  virtualization  technology  focuses  mainly 
on  processor  virtualization  for  consolidation  of  workstations  with  different  OSs  and  for  fail-over 
purposes  [2],  Since  many  other  components  within  the  workstation  platfonn  (i.e.,  on  or  attached 
to  the  motherboard)  affect  its  security  operation,  the  SCHW  architecture  will  address 
virtualization  issues  of  the  entire  platform,  not  just  the  processor.  Furthermore,  the  proposed 
hardware  features  will  afford  mobile  platforms  with  virtualization  technology  that  is  currently 
only  available  in  servers  and  high-end  desktops. 

The  SecureCore  platfonn  must  be  able  to  provide  the  following  capabilities. 

A.  Hardware  virtualization 

This  capability  must  support  Type  I  Virtual  Machine  Monitor  (VMM)  software  architecture  that 
can  host  multiple  unmodified  virtual  machines  (VMs)  [3].  For  the  SecureCore  project,  we  are 
exploring  an  architecture  in  which  the  LPSK  and  SCSS  layers  form  a  Type  I  VMM;  the  VMs  are 
the  guest  commercial  operating  systems  and  the  native  (SecureCore)  operating  system. 

The  virtualization  mechanism  must  provide  a  way  for  the  VMM  to  virtualize  all  system 
resources  such  as  processor,  memory  (including  cache  and  TLB),  interrupts,  and  I/O  devices.  In 
particular,  hardware  support  for  VM  scheduling,  as  well  as  task  scheduling  within  a  VM,  is 
required.  (F) 

R  Protected  processing  environment 

The  processor  architecture  must  provide  the  following: 

1 .  Support  for  a  partially  ordered  privilege  domain  architecture,  with  at  least  4  VM  privilege 
domains  and  2  VMM  privilege  domains.  The  VM  privilege  domains  are  available  to 
both  the  VMs  and  VMM  whereas  the  VMM  privilege  domains  are  only  available  to  the 


1  Due  to  the  research  nature  of  these  requirements,  their  imposition,  interactions  and  tradeoffs  will  require 
continuing  examination,  especially  for  those  designated  as  future  (F). 
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VMM.  (V) 

2.  Support  for  distinct  execution  entities  (viz.,  multitasking).  (Q 

3.  A  method  to  partition  the  modules  of  a  task  into  different  privilege  domains.  (Q 

4.  A  method  for  the  processor  to  transfer  control  directly  to  the  LPSK  when  a  non- 
privileged  portion  of  a  task  attempts  to  execute  a  privileged  instruction  that  might  violate 
the  security  policy.  (Q 

5.  A  method  for  virtualizing  the  interrupts  handling  mechanism,  including  support  for 
hardware-assisted  virtualization  of  the  interrupt  controller  chip.  (F) 

6.  A  method  for  restricting  access  to  I/O  devices.  (Q 

C.  Protected  memory  management 

The  platform  MMU  must  provide  the  following: 

1 .  Support  virtual  memory.  (Q 

2.  A  method  to  implement  distinct,  protected  per-VM  and  per-task  address  spaces.  (C) 

3.  A  method  to  enforce  fine-grained  memory  protection  policy.  Access  to  memory  will  be 
based  on  hardware  attributes  such  as  privilege  levels  and  access  modes. (Q 

4.  A  method  to  restrict  per-device  DMA  access.  ( N ) 

5.  A  method  to  prevent  information  leakage  through  memory  areas  (system  memory,  cache, 
and  Flash)  between  VMs,  including  timing  issues.  (AO 

D.  Secure  I/O  channels 

The  platfonn  must  provide  mechanisms  to  protect  the  confidentiality  and  integrity  of 
communications  between  the  I/O  devices  and  other  components  on  the  platfonn.  Minimally, 
secure  channels  must  be  provided  for  the  following  I/O  devices:  keyboard,  console  display 
device,  USB  devices,  and  network  interface  cards.  (AO 

£  Secure  boot 

The  platfonn  must  provide  the  following: 

1.  A  mechanism  to  ensure  the  integrity  of  the  BIOS  code  and  data  that  can  be  used  by  a 
ratcheting  bootstrap  scheme  [4],  e.g.,  a  “secure  root  of  trust”  such  as  might  be  provided 
by  the  SP  extension  discussed  in  Section  2.7.  (F) 

2.  A  privileged  mechanism  to  disable  selected  privileged  operations  as  the  operating  system 
initialization  progresses,  which  could  not  be  reset  until  the  processor  was  re¬ 
initialized^./7)  This  feature  would  provide  hardware  protection  against  modification  of 
structures  that  should  not  change  after  initialization  -  such  as  the  x86  LDT  for  a  static 
separation  kernel. 

F.  Secure  system  maintenance 

Most  modem  platforms  support  a  special  execution  mode,  i.e.,  system  maintenance  mode,  which 
can  bypass  all  protections  on  platfomi  resources  (e.g.,  memory,  I/O  devices).  A  typical  use  of 
this  mode  is  to  implement  various  power  saving  mechanisms  (e.g.,  powering  down  unused 
devices,  putting  the  system  to  sleep  or  hibernation).  The  SC  platform  must  provide  mechanisms 
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to  control  the  invocation  of  this  special  mode  as  well  as  to  protect  platform  resources  and  prevent 
information  leakage  between  VMs  when  it  is  invoked.  (F) 

C.  Concealed  execution  mode 

The  platfonn  must  support  the  integration  of  the  Secret  Protected  (SP)  architecture  to  provide  a 
safe  environment  for  per-user  cryptographic  processing  [5].  The  original  SP  design  must  be 
enhanced  to  support  virtualization  to  prevent  covert  channels.  The  SecureCore  “SP 
virtualization”  technical  report  describes  a  set  of  proposed  enhancements  to  virtualize  the  SP 
component  [6].  (F)  Additionally,  we  are  working  with  the  SecureCore  East  team  on  an  SP 
extension  to  support  high  integrity  enterprise  keys,  which  will  support  the  “transient  trust” 
functions  of  the  SP  architecture. 

H.  Trusted  platfonn  attestation 

The  platform  must  support  the  integration  of  a  trustworthy  hardware  attestation  component  to 
provide  the  ability  to  attest,  at  a  minimum,  the  presence  of  the  VMM.  ( N) 

I.  Hardware  isolation  of  security  critical  functions 

We  plan  to  work  with  hardware  vendors  to  extend  the  current  multicore  architecture  to  isolate 
processing  units  such  that  one  or  more  units  can  be  used  securely  for  privileged  mode  processing 
(i.e.,  kernel  functions),  and  for  dedicated  engines  such  as  the  SP  and  TPM.  This  isolation  feature 
will  also  facilitate  concurrent  execution  of  VMs,  i.e.,  multiple  VMs  can  be  isolated  by  hardware 
and  also  execute  at  the  same  time.  (F) 


III.  Summary 

This  document  presents  a  preliminary  set  of  high  level  requirements  for  the  SCHW  architecture. 
Table  1  characterizes  the  requirements  with  respect  to  their  technological  maturity. 


Table  1.  SecureCore  Hardware  Requirements 


Categories 

Requirements 

Currently  available 

II.B.2,  II.B.3,  II.B.4,  II.B.6,  II.C.l,  II.C.2,  II.C.3 

Next  generation 

II.B.l,  II.C.4,  II.C.5,  II.D,  II.H 

Future 

II. A,  II.B.5,  II.E.l,  II.E.2,  II.F,  II.G,  II  I 
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